npc@minotaur.jpl.nasa.gov wrote this... > > Dave Horsfall said: > > On Wed, 12 Apr 1995, der Mouse wrote: > > > > Maybe a good reason to join the crowd and not run NIS? > > > > > > I wish. It's clear to me that NIS is a big problem. But what else is > > > out there? We have a definite need to share passwd databases across > > > many machines, from multiple vendors, none of which we have source code > > > to. How close to a solution can we get? > > > > A wild idea, straight off the top of my head: what about using the DNS > > mechanisms? Apologies if this has been suggested and flamed before... > > A couple of points. First, in some sense, this has been implemented > (successfully) before. Find information on Project Athena's Hessiod > service. NIS like information was added to DNS in the form of > Hessiod records. > > The problem is that DNS isn't very secure either, plus that's a lot > more for DNS to handle, so, in general, I don't think it's a great > design idea, although it's convenient to use a mechanism that's already > in place. > > I'm surprised nobody's mentioned NIS+, although it's not available > everywhere yet (and I know of no freely distributable implementation). > Still, I'm not sure it's all it's cracked up to be. i mentioned this to the origional author, but not to the list. so here goes. NIS+ is much much more secure than NIS. it uses random timed credentials (somewhat like kerberos), and uses securerpc for communication. every entry in the table has an owner/group, and the table itself has an owner/group. it also has modes for four catagories of authentication nobody/owner/group/world (nobody is for non-authenticated connections, orld is for authenticated connections but not user/in group). within each catagroies restrictions are placed on 4 operations rmcd (read,create,modify,delete). thats it for the quick summary, now for some of the practical implications of this. every can own their own passwd entry, hence they can modify their own passwd entry but cant view it! but the root user can read the passwd entry but cant modify it, and no-one expect the NIS+ administers can create/delete a passwd entry. modes also affect table columns so that user can change their shell but not their full name, or vice versa. one note to all this, how this all works is up to how the administrator has set up NIS+ (you can achieve even nicer tricks if you understand NIS+ well). another capability is to have multiple NIS+ domains on one machine (but the machine will only use one for lookups of info). control is cool, but it makes for a few performance issues. NIS+ updates are almost instantaneous, if you lock a users account, they wont be able to log into any machine. the downside to this is that updating every record in a large table can take quite sometime (do it over night, and make sure your master NIS+ server has crunch to spare). if you only every do small updates you can get by on a small machine (we run all our mail/pd software/NIS+/printing on a sparc2 running solaris 2.4, and this is for over 3000 users. this setup runs fine most of the time, mail seems to give us more CPU hassles than NIS+). anyway enough of that... if anyone wants more info on how NIS+ works/what it is capable of, mail me (we have been running it here for almost 6 months). on a final note, if you need distributed, secure, updatable network files, NIS+ is a good option (unfortunatly it only runs on Solaris/SunOS right now (yes!! it runs on SunOS! but i havent tried on SunOS yet)). Matt -- #!/bin/sh echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit Matthew Keenan Systems Programmer Information Technology Division University of Technology Sydney Australia It's nice to be in a position where people apologize because they assume there's humor in your work, based on past experience, but they're not sure where it is. -- Rob Pike